A file server is a computer that provides file service relating to the organization of information on writeable persistent storage devices, such as memories, tapes or disks. The file server or filer may be embodied as a storage system including a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g., the disks. Each “on-disk” file may be implemented as set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
A filer may be further configured to operate according to a client/server model of information delivery to thereby allow many client systems (“clients”) to access shared resources, such as files, stored on a server, e.g., the filer. In this model, the client may comprise an application, such as a file system protocol, executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. Each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the filer over the network. By supporting a plurality of file system protocols, such as the Network File System (NFS) protocol, the Direct Access File System (DAFS) protocol and the Common Internet File System (CIFS) protocol for the Microsoft® Windows™ operating system, the utility of the filer may be enhanced for networking clients.
There are known mechanisms used for synchronizing access to a common shared resource or set of resources, many of which are based on the use of semaphores. A semaphore is a variable, such as a hardware or software flag, with a value that indicates the status of the shared resource. To keep users, such as clients, from interfering with one another, a semaphore may be used to lock the resource. In this context, a lock is an abstraction that represents the right to access a resource or set of resources. Clients that access a shared resource obtain a lock that corresponds to that resource before manipulating its contents.
Locks may be mandatory, in which case the filer requires that no other client holds the corresponding lock when a request is made that affects this resource, rejecting the request if there is such another client. In this “mandatory” case, clients obtain locks to ensure that their requests to manipulate such resources cannot be rejected. Other locks are advisory, in which case the filer does not enforce any constraint on corresponding resources. In the “advisory” case, client applications establish their own convention that certain operations may only be performed with certain “held” locks. When adhered to by the client applications, this convention ensures that no destructive interference between clients can arise.
Resource contention arises when more than one client attempts to request exclusive access to a single shared resource or set of resources. A lock controller (manager) is a mechanism that may be used to determine which client may obtain the requested resource. To that end, the lock manager selects one client from among the plurality of requesting clients, typically in accordance with some arbitration policy. The other clients must then wait for the resource to be released before they can obtain access to it.
Prior support for locking on a multi-protocol storage system, such as a filer, utilized a conventional lock manager approach that supported only a limited number of file access protocols. That is, the prior lock manager approach did not provide support for a variety of file access protocols, but rather only supported a set of popular protocols such as, e.g., CIFS and NFS. It should be noted that locks for NFS versions 2 and 3 are generally obtained using a separate network lock manager (NLM) protocol; however, the combination of NFS and NLM is considered herein as a single integrated file access protocol, e.g., NFS.
In addition, the conventional lock manager approach provided no “clean” separation between protocol-specific processing and locking semantics. Program code in the prior lock manager contained explicit checks for lock compatibility, which included specific checks on the protocol associated with a requested lock. Such an approach is difficult to maintain with a limited number of supported protocols and may rapidly become unworkable (impractical) as further protocols are supported.
Moreover, only one of the supported protocols, e.g., CIFS, provides for revocable locks, which obviated the need to provide general support for such locks, including opportunistic locks, delegations and locks associated with expired leases. The CIFS protocol supports sharing of files and data between multiple Windows clients and, in fact, leverages such file sharing in its implementation of a Windows networking performance optimization known as “opportunistic locks” (oplocks). There are a number of types of oplocks. An exclusive oplock is a revocable exclusive (i.e., prevents, while held, all access from other clients) file lock that a Windows client obtains “opportunistically” at file open time if the file being opened is not currently being accessed by any other application. A shared (or type-2) oplock is a revocable shared (i.e., may be held by a number of clients) file lock that a Windows client also may obtain “opportunistically” when a file is being opened for reading if the file being opened is not currently opened for writing by any other application.
NFS Version 4 (NFS-v4) differs from previous versions of NFS by allowing a server to delegate specific actions on a file to a client to enable aggressive client caching of data and to allow caching of locking state. A server cedes control of file updates and locking state to a client via a write delegation, subject to recall of that delegation by the server. According to the NFS-v4 protocol, when only a single client references a file, the server may delegate responsibility for handling all open, close and locking operations to the client. Since the server on granting a delegation guarantees the client that there can be no conflicting open operations, the cached data is assumed valid. The server may also allow the client to retain modified data on the client without flushing at close time, if it can be guaranteed that sufficient space will be reserved on the server ensuring that subsequent write operations will not fail due to lack of space.
NFS-v4 also enables a server to allow multiple clients the ability to access file data in a non-interfering manner by means of a read delegation, subject to recall by the server. The NFS-v4 protocol allows the server to delegate to the client responsibility for handling open operations that do not specify write access or the denial of read access. This allows the client to cache unchanged file data without interacting with the server.
In order to deal with potential problems that would arise when a client system holding one or more locks ceases to function, and so is unable to release its lock, the NFS-v4 protocol associates client locks with leases, which represent the right of the client to have its locks maintained. Such leases are of limited duration with the expiration interval set by the server, but subject to renewal. The client system, in order to be assured of continued possession of its locks must periodically renew its lease. When a lease is not renewed in a timely fashion, the server may release all locks associated with the expired lease, or more desirably, make the locks revocable, in that a conflicting lock request by another client will be granted. However, if the lease is renewed before any such conflicting lock, the associated locks again become “normal” locks not subject to revocation in the event of a conflicting lock.
The DAFS protocol also provides support for delegations and leases in a manner similar to NFS-v4.
Therefore, an object of the present invention is to provide an improved lock manager that provides support for a variety of different file access protocols, including support for various types of revocable locks. CIFS oplocks, NFS-v4 and DAFS delegations, and NFS-v4 and DAFS locks associated with expired leases are all examples of revocable locks.
Another object of the present invention is to provide an improved multi-protocol lock manager having a locking model that is not “protocol-centric”, but that accommodates different implementations of revocable lock-like features in the different protocols.
Yet another object of the invention is to provide a multi-protocol lock manager having a maintainable framework that efficiently performs file locking, while generally hiding implementation details from subsystems that implement the specific protocols and file system operations.